Storage controllers such as, for example, SCSI and serial attached SAS controllers represent a set of standards for physically connecting and transferring data between computers and peripheral devices. The SCSI standards, for example, define commands, protocols, and electrical and optical interfaces. SAS controllers typically employ a serial, point-to-point topology to overcome performance barriers associated with a storage device based on a parallel bus or arbitrated loop architecture.
Conventionally, an embedded firmware associated with a LSI storage controller is responsible for starting and completing all SCSI I/Os from a host driver/operating system. The SAS controller raises an interrupt to notify the firmware regarding the arrival of a new I/O request when the host submits the I/O request to a SAS controller message unit. The firmware services the interrupt, validates the SCSI I/O request, verifies that a target device is capable of accepting the I/O, and then interfaces with a SAS core to transmit a command frame to the target device and initiate data transfer. Once data transfer completes, the target device will return a response frame to the controller, causing the SAS core to raise a completion interrupt. The firmware further services such completion interrupts and subsequently interfaces with the messaging unit to pass a response back to the host.
Some prior art storage controllers may include, for example, a fast path engine hardware functionality that permits the SCSI I/O requests and completions to flow back and forth between the messaging unit and the SAS core without any firmware involvement and/or knowledge. The majority of prior art controllers, however, do not include fast path engine hardware. An I/O path and error condition with respect to such storage controller includes, for example, an active task management cleanup for the device, handling certain types of I/O requests not automated by the hardware, sending certain kinds of primitives to the SATA devices, and some types of I/O path exceptions (e.g., when a device briefly goes missing from the SAS topology). Such SAS topology conditions and device errors however, periodically require the SAS controller's firmware to take control of the fast I/O path and re-direct the flow of I/Os through firmware. Additionally, such an approach is not capable of controlling the device I/O path when multiple entities submit I/O request simultaneously.
A state machine can be alternatively adopted for each firmware in order to clear the I/O path exceptions and to directly manage corresponding fast path engine hardware control settings. Such an approach additionally requires an enormous amount of tracking logic to handle scenarios when multiple types of I/O path exceptions occur. Because the firmware associated with the SAS controller is spread across multiple software modules/source files and maintained by multiple engineers simultaneously, such approach, however, leads to increased number of software bugs and invite development of difficult-to-maintain “spaghetti code”.
Based on the foregoing, it is believed that a need exists for an improved system and method for coordinating control settings with respect to an automated input/output (I/O) processor. A need also exists for configuring a state machine to control an I/O path with respect to multiple entities, as described in greater detail herein.